Follow the framework: no favicon field, a fixed page title, types and the exit interface under their new names - #172

abap2UI5 fixes the generated page's <title> to `abap2UI5` and stops
reading `cs_config-title` (abap2UI5/abap2UI5, on main). The tab title is
`cs_event-set_title` from the running app, and nothing else.

Four pages said otherwise, one of them by example:

- User Exits taught `cs_config-title = 'my title'` as the first line of
  the first example every reader copies. The line is gone, the sentence
  above it no longer promises the page title, and a warning says the field
  still compiles but does nothing.
- Setup called the title one of the things the generated index.html gets
  configured with; it now says the tab title is not on that list and where
  it is set instead.
- Title (cookbook) leads with the rule: the page always carries
  `<title>abap2UI5</title>`, that is what the tab shows while UI5 boots,
  and from the first roundtrip on the app owns it.
- Deprecations has the row and the section, old code next to new, marked
  *next release* - it is on main and in no release yet.

Release notes untouched: the field is not gone, and the behaviour change
belongs to the version that ships it.

abap2UI5 retires `z2ui5_if_types`: every type it held now sits on the object
whose signature is the reason it exists — `ty_s_get` and `ty_s_event_control`
on `z2ui5_if_client`, the three HTTP config types on `z2ui5_if_exit`,
`ty_s_draft` on `z2ui5_cl_ui5_srv_draft`, `ty_s_config` written out inside
`ty_s_get`.

Deprecations gets the row and a section with the full old-to-new table, and
says the part that decides whether anyone has to act: the interface still
ships unchanged from the frozen package and every moved type is identical
field for field, so existing code compiles and still fits the new
signatures. Marked *next release* — it is on main and in no release yet.

Renaming listed `z2ui5_if_types` as one of the four segment-less public
interfaces. It is three now, with the fourth named as what it became.

abap2UI5 renames `z2ui5_if_exit` to `z2ui5_if_ui5_exit` (on main). Both
interfaces ship and the framework looks up both, so an existing exit class
is found and called exactly as before.

Deprecations gets the row and a section with both class skeletons next to
each other, and states the part that decides whether anyone has to act: a
class implementing the old interface keeps working, one implementing both is
called once through the new one, and the old interface's types are
references to the new one's rather than copies. Marked *next release*.

User Exits gets a tip, because it is the page somebody reads while writing
an exit. The example there still writes `z2ui5_if_exit` — every fenced ABAP
example on this site is compiled against the RELEASE, and the new name is
not in one yet. The examples follow when it is.